The Web Design Group presents:

INPUT TYPE=IMAGE for text users?


INPUT TYPE=IMAGE is another of those situations where text-mode readers will be disadvantaged, if the author had not given them due consideration. Unlike the IMG tag, this one does not have an ALT text attribute.

More details of browser behaviour in this respect can be found in some associated documents. The HTML2.0 spec only considers the situation where NAME=nnn has been specified (and no VALUE attribute), but there is no definite specification of what a text-mode browser should do. Some known combinations are tabulated below: c,d represent decimal values of x, y co-ordinates in pixels, nnn and vvv are character strings, & is the standard forms-submission separator and (although not shown) form contents are sent encoded in the way that is specified by the standard. (Browsers are somewhat erratic as to whether they send a space as "+" or "%20", but that is not discussed here as it will normally be resolved by whatever forms-analysis library you are using.)

WinMosaic 2.1, when the NAME attribute was omitted, bizarrely used the NAME that had been specified on the earlier TYPE=IMAGE item!

Form submission by INPUT TYPE=IMAGE
with various combinations of NAME and VALUE
Browser Neither NAME=nnn [*] VALUE=vvv Both
Netscape2.0 x=c&y=d nnn.x=c&nnn.y=d vvv ignored
WinMosaic2.1See text! nnn.x=c&nnn.y=d vvv ignored
Lynx2-4 & FM(none) nnn.x=0&nnn.y=0 (none) nnn=vvv
emacs-w3 .x=0&.y=0 nnn.x=0&nnn.y=0 vvv ignored

The column marked [*] is the situation specified in the HTML2.0 standard

The most consistent behaviour can be seen to be the one specified in the standard (not suprisingly). Provided due consideration is given to the fact that text-mode users only send co-ordinate values 0,0, all browsers give equivalent results.

In the situation where the IMAGE is used merely as a decorative SUBMIT button, provided the form analysis software is programmed to disregard the various forms of the x,y response, all should be well even if the NAME is omitted, but then it's not possible to determine which of several buttons was pressed. The presence of a VALUE attribute affects what Lynx displays (but not emacs-w3), as well as affecting what Lynx sends (but not emacs-w3).

From Foteos Macrides' mail to me, I have the distinct impression that he had intended that authors might supply a VALUE attribute, and detect the difference between Lynx and other browsers by testing the result: this would seem to me a commendable way of dealing with text-mode browsers, if it was documented and obeyed by them all. As it is, authors can provide a VALUE attribute, if they wish to get it displayed by Lynx; but this has no effect on emacs-w3 (neither in respect of its display nor in respect of what it sends), and if they wish to deal with all possible browser responses, they'll then have to be prepared for Lynx's nnn=vvv response as well as emacs-w3's nnn.x=0&nnn.y=0 response.


The contents of this article were originally published at http://ppewww.ph.gla.ac.uk/%7Eflavell/alt/type-image.html, where they are currently maintained.

Original materials © Copyright 1994, 1995, 1996 A.J.Flavell & Glasgow University


Home, Questions, Members, WDG Award, Reference, Design, Links

Web Design Group